Web sites, or Internet sites, very often provide information, products, services, or the like to their users. Many web sites require users to “register” before the sites' web servers will grant access to the users. During registration, a user typically supplies personal information such as username, account number, address, telephone number, e-mail address, computer platform, age, gender, and/or hobbies. The registration information may be necessary to complete transactions (e.g., commercial or financial transactions). Additionally, web sites often collect user information so web site operators can better target future marketing activities or adjust the content provided by the sites. The collected information may also enable web sites to contact users directly (e.g., via e-mail) to announce, for example, special promotions, new products, or new web site features.
When registering a user for the first time, the web site typically requests that the user select a login ID and an associated password. The login ID allows the web site to identify the user and retrieve the user's information during subsequent user visits to the web site. Generally, the login ID must be unique to the web site such that no two users have the same login ID. The password associated with the login ID allows the web site to authenticate the user during subsequent visits to the web site. The password also prevents others (who do not know the password) from accessing the web site using the user's login ID. This password protection is particularly important if the web site stores private or confidential information about the user, such as financial information or medical records.
If the user visits several different web sites, each web site may require entry of similar registration information about the user, such as the user's name, mailing address, and e-mail address. This repeated entry of identical data is tedious when visiting multiple web sites in a short period of time. Many web sites require the user to register before accessing any information provided on the site. Thus, the user must first enter the requested registration information before he or she can determine whether the site contains any information of interest.
After registering with multiple web sites, the user must remember the specific login ID and password used with each web site or other Internet service. Without the correct login ID and password, the user must re-enter the registration information. A particular user is likely to have different login IDs and associated passwords on different web sites. For example, a user named Bob Smith may select “smith” as his login ID for a particular site. If the site already has a user with a login ID of “smith” or requires a login ID of at least six characters, then the user must select a different login ID. After registering at numerous web sites, Bob Smith may have a collection of different login IDs, such as: smith, smith1, bsmith, smithb, bobsmith, bob_smith, and smithbob. Further, different passwords may be associated with different login IDs due to differing password requirements of the different web sites (e.g., password length requirements or a requirement that each password include at least one numeric character and/or at least one uppercase character). Thus, Bob Smith must maintain a list of web sites, login IDs, and associated passwords for all sites that he visits regularly.
Although presently available multi-site user authentication systems permit a web user to maintain a single login ID (and associated password) for accessing multiple web servers or services, further improvements are desired. For example, a web server typically sends a “cookie” to a browser to capture the current state of a web session and stores the cookie on the user's local system to identify the user and maintain the session. In general, a cookie is a block of data that a server returns to a client in response to a request from the client. The browser automatically includes the cookie in subsequent communications with the server. Otherwise, the user would be required to repeatedly re-enter username/password information in, for example, an authentication session. Unfortunately, the use of cookies presents potential security risks for the user. Those skilled in the art are familiar with cookies and their use by server side connections to both store and retrieve information on the client side of the connection.
Presently available web browsers maintain no state with a web server other than the cookie, which is a client state object. When the user returns to a particular web site, the browser sends a copy of the appropriate cookie back to the server to identify the user or otherwise submit information to the server on behalf of the user. The cookie has a domain attribute that must match the server's domain for the server to access the cookie. The server typically uses this information for customizing and retaining the site's settings for the user across multiple sessions. Cookie syntax and structure, including the presence of a domain attribute for comparison to the domain of the host from which information will be fetched, are well known in the art. Moreover, one of ordinary skill in the art would expect an authentication system to store critical security information in cookies. Although each site should maintain its own cookies on the user's machine and be able to access only those particular cookies, the potential exists for unauthorized access to cookies and the potentially sensitive information stored in them.
Those skilled in the art are familiar with script injection as a common attack on a cookie-based system. One technique for injecting a script (i.e., downloading from the server to run on the client) is to deceive the user with a bogus user interface (e.g., “click here for free tickets”). Another technique for injecting a script involves the use of overlapping frames in which the attack content remains unseen by the user because real content overlaps it. In any event, the malicious script injected into a web page can access the cookies, which creates a security breach. Conventional techniques for safeguarding against script injection include input and/or output filtering to turn off script injection. Unfortunately, it is difficult to filter out every type of script and every script. Therefore, these filtering techniques require laborious efforts in development and testing to ensure that every piece of input/output data is scrutinized carefully. As an example of conventional output filtering used on an authentication site, the Hypertext Markup Language (HTML) source includes the following HTML statement:
<input TYPE=“hidden” NAME=“ru”
value=“http://www.authsite.com”>$script$alert$document.cookie$$$/script$”>
In this instance, the $ characters have replaced the “< >;” on the query string. As described above, this technique is highly laborious and requires attention to detail across a large development team, particularly in the context of a multi-site user authentication service affiliated with a large number of web services.
Further, filtering out script injection fully is not possible for certain web-based functionalities (e.g., co-branding of web sites). Co-branding, which involves content aggregation between sites, relies heavily on third party client scripts. For this reason, it is practically impossible to enforce correct input/output filtering among all of the affiliated sites. In addition, all of the different encoding rules used in html make the task of preventing script injection through filtering very likely to fail. Filtering out script injection can also lead to malformed input/output data.
For these reasons, a browser security model is desired for preventing access to a user's cookies by client scripts without the need for labor-intensive and error-prone filtering techniques. In other words, a reliable solution to script injection is desired, particularly for use in a cookie-based web authentication system.